Transport Across Environments (Dev -> QA -> Prod)
Transport Strategy Overview
WorkNet uses the same CI/CD transport pattern as all CAF components:
Developer Git Push -> Azure Pipeline -> Container Registry -> Target Environment (CF / K8s)
Application Code Transport (Docker Image)
| Step | Action | Details |
|---|---|---|
| 1 | Developer pushes code | To Azure DevOps Git repository |
| 2 | Pipeline triggers | Builds JAR, builds Docker image |
| 3 | Image pushed to ACR | wblnd.azurecr.io/worknet:<build_number> |
| 4 | Deploy to DEV | Use dev manifest (auto/manual) |
| 5 | Deploy to QA | Use QA manifest (manual approval gate) |
| 6 | Deploy to PROD | Use prod manifest (manual approval gate) |
Key principle: Same Docker image, different configuration per environment.
Environment-Specific Configuration
Each environment uses a different Config Server profile (spring.application.name):
| Environment | Config Server App Name | Config Differences |
|---|---|---|
| DEV | sbx-worknet-dev | Dev DB, dev service URLs, dev auth |
| QA | qa-worknet | QA DB, QA service URLs, QA auth |
| PROD | prod-worknet | Prod DB, prod service URLs, prod auth |
YAML Config Transport
YAML configurations (DB structure, action configs) live in the database per environment:
- Must be uploaded via
/v1/yaml/uploadAPI in each environment - Or managed via Config Server (if
readYamlFromConfigprofile is active)